The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
There is an increasing demand for using untrusted networks, like the Internet, for secure transmission of private and confidential information. An untrusted network includes one or more networking devices that are not under control of the parties sharing the private or confidential information. A variety of interacting protocols have been developed to support secure transmissions over untrusted networks. For example, an IPSec protocol has been promulgated to support virtual private networks (VPNs) over wide area networks that employ the Internet Protocol (IP) for data packet switching. IPSec is an open standard protocol for secure data transfer within IP data packets, as described in Request For Comments (RFC) 2401, among others, available at the time of this writing on the World Wide Web (www) at domain ietf.org.
IPSec involves the use of secret long integers, called keys, to encrypt and decrypt payloads sent in Internet Protocol (IP) data packets, or to authenticate sources of those data packets, or to ensure the payloads have not been tampered, or to perform some combination of these functions. Establishing one or more pairs of keys to use in secure communications, at least temporarily, between two or more communicating parties (“peers”) requires some key exchange mechanism. The peers are typically network devices, such as routers, at the edge of the untrusted portion of the network.
Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange and is designed to support many different key exchanges. ISAKMP is described in RFC 2408, available at the time of this writing at domain ietf.org. A security association (SA) describes how peers utilize security services to communicate securely. For example, an IPSec security association for a set of peers defines the encryption algorithm, if any, the authentication algorithm, and the shared session key to be used during an IPSec connection. A particular combination of values identifying an encryption algorithm, an authentication method, a one-way hash function, a parameter in an exchange algorithm, and a lifetime for the security association forms a particular security policy for the security association. A security association for a set of peers is made up of the particular policy and the actual keys determined after the exchange. The Internet Key Exchange (IKE) is one protocol for generating and exchanging keys within the ISAKMP framework for IPSec. IKE is described in RFC 2409, available at the time of this writing at domain ietf.org.
An extension of ISAKMP, called ISAKMP “Config Mode,” allows a remote client communicating over an untrusted network to connect to a trusted network through a gateway and be configured by a policy server on the trusted network for IKE secure communications. Config Mode is described in a document available, as of this writing, as file “draft-dukes-ike-mode-cfg-latest.txt” at domain and directory employees.org/˜ddukes on the World Wide Web. Example known policy servers include a Remote Access Dial-In User Service (RADIUS) server and a Terminal Access Controller Access Control System Plus (TACACS+) server, among others.
The gateway on the edge of the trusted network connected to the untrusted network receives an ISAKMP Config Mode request message from the client for security configuration information. In some configurations, the gateway uses information in the ISAKMP Config Mode request message to generate a request according to the protocol of the policy server, e.g., using the RADIUS or TACACS+ protocol. The policy server authenticates the client and determines which IKE secure services the client is authorized to obtain. The IKE parameters are returned to the gateway. The gateway uses this information to generate and send an ISAKMP Config Mode reply message to the client. The client uses the information in the ISAKMP Config Mode reply message to configure itself for secure communications with the gateway. The peers in the subsequent IPSec communications are the client and the gateway. One or more additional ISAKMP request and reply messages may be undertaken to establish the security association for IPSec tunnels between the client and the gateway over the untrusted network.
A problem arises with Config Mode when the security policy for a remote client is extended with additional security attributes. In addition to the security association shared by the gateway and the client, there may be additional behavior demanded or allowed of the client that does not involve its communication with the gateway, but rather its behavior toward other hosts connected to the trusted and untrusted networks. This additional behavior is described in additional security attributes of an extended security policy. For example, an additional security attributes might include a firewall policy to employ at the client edge of the untrusted network, among other additional attributes.
If the gateway does not know how to interpret the request for additional attributes in the ISAKMP Config Mode request, then the gateway does not know how to construct the message to send to the policy server according to the policy server protocol. If the gateway does not know how to interpret the message from the policy server, which includes the additional information from the policy server, then the gateway does not know how to construct the ISAKMP Config Mode reply message to send to the client. Therefore, when new security attributes are added to an extended security policy, the policy server and client are modified to use the new security attributes, and the gateway also must be modified to handle the new security attributes in Config Mode. The gateway Config Mode process is modified even when the new security attributes do not affect the security association between the gateway and client.
Reprogramming security gateways with each new security attribute used to configure remote clients is undesirable. Many different devices, with different software and different operating systems serve as security gateways. Modifications to all of them may involve multiple reprogramming efforts and extensive testing to ensure corresponding behavior in similar circumstances. In addition, because updated versions of these devices and software are released at different times, it is difficult to synchronize the behavior of all these devices with respect to new features, such as new security attributes exchanged via Config Mode.
Based on the foregoing, there is a clear need for techniques that allow security policy attributes for remote clients to be extended without reprogramming security gateways with each extension. In particular, there is a need for techniques that allow IKE policy attributes for remote clients to be extended without reprogramming an ISAKMP gateway.